Security Levels for Access Checks

Security is checked only at application boundaries. That is, for two components in the same application, when one component calls the other, no security check occurs. However, if two applications share the same process and a component in one calls a component in the other, a security check is done because an application boundary is crossed. Likewise, if two applications reside in different server processes and a component in the first application calls a component in the second application, a security check is done. Therefore, if you have two components and you want security checks to be done when one calls the other, you need to put the components in separate COM+ applications.

Because COM+ library applications are hosted by other processes, there is a security boundary between the library application and the hosting process. Additionally, the library application doesn't control process-level security, which affects how you need to configure security for it. For more information, see Library Application Security.

Component-Level Access Checks

For a COM+ server application, you have the choice of enforcing access checks either at the component level or at the process level. When you select component-level access checking, you enable fine-grained role assignments. You can assign roles to components, interfaces, and methods and achieve an articulated authorization policy. This is the standard configuration for applications using role-based security. For COM+ library applications, you must select component-level security if you want to use roles.

You should select component-level access checking if you are using programmatic role-based security. Security call context information is available only when component-level security is enabled. Additionally, when you select component-level access checking, the security property is included on the object context. This means that security configuration can play a role in how the object is activated.

Process-Level Access Checks

Process-level checks apply only to the application boundary. That is, the roles that you have defined for the whole COM+ application determine who is granted access to any resource within the application. No finer-grained role assignments apply. Essentially, the roles are used to create a security descriptor against which any call into the application's components is validated. In this case, you would not want to construct a detailed authorization policy with multiple roles. The application uses a single security descriptor.

For COM+ library applications, you would not select process-level access checks. The library application runs hosted in the client's process and hence does not control process-level security. For more information, see Library Application Security.

With process-level access checks enabled, security call context information is not available. This means that you cannot do programmatic security when using only process-level security. Additionally, the security property is not included on the object context. This means that when using only process-level access checks, security configuration never plays a role in how the object is activated.

For step-by-step instructions on setting the security level for access checks, see Setting a Security Level for Access Checks.